Ultimate Automizer with Two-track Proofs - (Competition Contribution)

Ultimate Automizer is a software verification tool that implements an automata-based approach for the analysis of safety and liveness problems. The version that participates in this year’s competition is able to analyze non-reachability, memory safety, termination, and overflow problems. In this paper we present the new features of our tool as well as the instructions how to install and use it. 1 Verification Approach Ultimate Automizer implements an automata-based approach to software verification that we call trace abstraction[4]. The key concept in this approach is the notion of a trace which is a sequence of program statements. We consider a program as a set of traces, namely the set of all traces that are labellings of paths in the control flow graph. For the verification of a property, we start with all traces that potentially violate the property, e.g., for checking non-reachability of an error location we start with all traces that lead from the initial location to the error location. Then, we iteratively prove that all these traces are infeasible, i.e., we prove that none of these traces corresponds to a concrete program execution. In each iteration we take a sample trace π that potentially violates the property and analyze its feasibility. If the trace π is feasible, we found a concrete counterexample to the validity of the property. Otherwise, we construct a proof for the infeasibility of π. Next, we generalize the trace π to a set of traces that are infeasible and whose infeasibility can be shown using the proof that was constructed for π. We use automata to represent sets of traces. The underlying alphabet is the set of all program statements. The traces that potentially violate the nonreachability property are the words that are accepted by the automaton that resembles the control flow graph of the program and whose final state is the node that corresponds to the error location of the program. The procedure for obtaining sample traces is implemented as an emptiness check and in each iteration we use a difference operation on automata to ensure that we exclude all traces whose infeasibility was already shown. ? This work was partly supported by the German Research Council (DFG) as part of the Transregional Collaborative Research Center “Automatic Verification and Analysis of Complex Systems” (SFB/TR14 AVACS) In the following we present new features of this year’s competition candidate. Two-track proofs. In former versions of our tool, the above mentioned infeasibility proof for a trace was an inductive sequence of state predicates. Such a sequence was obtained via Craig interpolation or via a technique that combines unsatisfiable cores, live variables and the post predicate transformer. In this year’s competition contribution, we use this technique to compute two sequences of predicates. One sequence is obtained by the post predicate transformer, the other sequence is obtained by the wp predicates transformer. A second sequence of predicate is redundant to prove the infeasibility of the trace π but it improves the generalization from one infeasible trace π to a set of infeasible traces. Semi-deterministic Büchi automata. In our termination analysis we consider infinite traces and use Büchi automata to represent sets of traces[5]. The subtraction of traces whose infeasibility was already proven involves the complementation of Büchi automata which is known to be expensive. In order to overcome this bottleneck, we adjusted our algorithm such that the input of complementation operations is always a semi-deterministic Büchi automaton. This allows us to use a specialized complementation whose result has at most 4 states[2]. Bitprecise analysis. We use SMT-LIB to represent sets of program states and the transition relation of program statements. First, we try to verify a program by using the theory of (mathematical) integers. In order to soundly capture the semantics of machine integers we use modulo operations and we overapproximate bitwise operations, e.g., bitshifts, by a havoc operation. Whenever this analysis returns a counterexample that contains an overapproximated bitwise operation, we redo the analysis and use the SMT-LIB theory of bitvectors.